1. Field of the Invention
This invention relates to database storage systems and, more particularly, to techniques for creating snapshot copies of a database.
2. Description of the Related Art
Many business organizations and governmental entities rely upon large databases, sometimes exceeding a terabyte or many terabytes of data, for mission-critical applications. It is common that many such database applications require near-continuous access. For example, many systems such as retail processing databases, airline reservation databases, and financial institution databases must be available to perform transaction processing 24 hours a day. Downtime associated with such systems can be disastrous.
With the growing amounts of data and shrinking acceptable downtime requirements of modern database systems, organizations are sometimes squeezed by the conflicting demands associated with a database environment. For example, secondary operations such as data backup operations, reporting and analysis, and application testing can be of significant importance. However, such secondary operations can interrupt or encumber the normal transaction processing of a host system running a database application.
To minimize these problems, some systems support snapshot capabilities that allow point-in-time copies of data to be created. By creating snapshots of the appropriate storage devices, a frozen image of the database can be created and can then be used to facilitate the secondary operations. For example, the snapshot copies containing the image can be installed on a secondary host that performs the secondary operations. In this manner, availability of the primary host for normal transaction processing can be maximized.
The creation of snapshot copies can be based on data-mirroring technology implemented by a volume manager running on the host system. In a data mirroring configuration, identical copies of data are stored on different physical storage devices. A volume-level snapshot can be created simply by splitting and detaching a mirror containing an image of the data from the original volume. Once the user has completed use of the snapshot volume split from an original, it may be resynchronized (since continued updates to the original volume may have occurred) by reattaching it to the original. Subsequent snapshots may be taken in a similar manner.
While the volume level snapshot capabilities of a volume manager may be utilized to create a snapshot of a database object, several significant problems can be presented. Firstly, storage is typically managed by system administrators or storage administrators who have root privileges which may be required for invoking the snapshot capabilities of a volume manager. In many organizations, database administrators do not have root privileges. Accordingly, the system administrator and database administrator must typically work together to coordinate the database and its storage when creating a snapshot.
In addition, even if the database administrator were granted root privileges, they often do not have the storage management expertise to effectively utilize the snapshot functionality of the volume manager. Creation of a consistent frozen image for a database, especially large databases that use hundreds of disks, is a complicated process and may be error prone. A single error may render the entire frozen image useless.